Field of the Invention
The present invention relates to the field of model driven development and more particularly to reporting tools for reporting information contained in models produced in model driven development.
Description of the Related Art
Modern software systems have become increasingly pervasive and open-ended, and are expected to deliver critical computing services in a dependable manner across multiple, heterogeneous, computing environments. To better manage the complexity of developing modern software systems, software development strategies can be employed which raise the level of abstraction at which software systems are conceived, implemented and evolved. Model-driven development (MDD) represents one such software development strategy in which models are the primary artifacts of software development.
Modeling complex applications has several general benefits that can include a better understanding of the business or engineering situation at hand, the construction and design of application architectures, and the creation of visualizations of code and other forms of implementation. In this regard, the essence of modeling is abstraction and any visualization of code is indeed an abstraction in that application information can be selectively exposed while details deemed unnecessary or unwanted can be suppressed. In conventional MDD, visual models can be created utilizing model constructs or model types.
In a typical model driven development (MDD) process, models are first-class artifacts, and as such, consume a substantial amount of time and effort at the outset so that the models be used to generate lower level models and ultimately source code. Consequently, tools that help gain better understanding of the information contained in models are known to be very useful. Reporting tools for MDD are an important aspect of MDD and allow for the creation of custom views of the information contained in models—views that are easier to consume especially by non-technical individuals. At present, many reporting tools have been marketed for use in creating reports of information contained in models.
Notwithstanding, the use of reporting tools does not come without complication. Specifically, a discrepancy often exists between the format of data expected by the reporting tool and the format of data chosen for a model under consideration by the reporting tool. In this regard, a common format of models is the format proposed by the Object Management Group (OMG)—essentially a hierarchy of structured data that follows a meta-model or a schema. The OMG proposed format utilizes the extensible markup language (XML) variant, XML meta-data interchange (XMI) as a format for persisting models. In concert with XMI, the Eclipse Modeling Framework (EMF) provides a popular framework with services for defining meta-models, abstract syntax for modeling languages, which can be used to create conforming models and persisting them in XMI.
Notably, some of the more popular reporting tools such as the open-source Business Intelligence Reporting Tool (BIRT)—a plug-in to the Eclipse environment—are not designed to read structured data of models in its native format. Rather, most popular reporting tools are designed to handle data structured in the format of a database, specifically tables with rows and columns. To that end, it is thus required to map the structured representation of models to a database representation. This approach has been adopted in reporting tools by providing a generic XML based data mapping extension that is able to consume models as XML data that follows a certain XML schema. Such extensions use an XML-based query language, for instance “Xpath”, as a query engine operating on the data of the model.
Nevertheless, some issues remain in using such solution for reporting on models in a MDD environment. In particular, XMI semantics are not completely described by XML; for example, XMI has the notion of multiple-inheritance that does not exist in XML. This incongruity results in the loss of information in transforming the information of the model from a native format to a database format. Also, model implementations often provide an application programming interface (API) that applies to the model data. In consequence, viewing a model through an API as pure data inhibits the ability to extrapolate useful information easily from models in the mapping process.
Addressing these inherent deficiencies, a two-phase approach has been proposed in which the first phase transforms models into simple XML data that can be easily consumed by the XML mapping process and the second phase performs the XML mapping. The XML transformation, however, introduces performance penalties resulting from additional required upfront processing, and complexity designing a new report-friendly XML schema and designing a mapping from the various meta-models to the new report friendly XML schema. These problems are often amplified if attempting to do a complete schema mapping that fits any report generically, rather than a tailored mapping for every report.